最近。age0提出了一个OO设计的问题。因为这个例子更加贴近生活，是我们老百姓所喜闻乐见的商场折扣问题，所以我准备改铉更张用这个例子了。具体的例子请看： http://forum.javaeye.com/viewtopic.php?t=17714&start=0
简要的说，需求是： 引用:
有这样一家超市，对顾客实行会员制，会员目前分为两个等级：金卡及银卡。 每次会员购物时，都会根据会员等级提供不同的折扣优惠和返点。
这个需求并不复杂。任何一个普通的java程序员都可以轻松搞定。 age0就给出了几个方案供大家选择。
一个大家普遍认可的方案是： java代码:
// client:
string id = input_id;
Member member = Members.GetMemberByID(id);
int discount = member.GetDiscount();
int point = member.GetReturnPoint();
// service
class Members
{
static public Member GetMemberByID(string id)
{
string type = GetMemberTypeByID(id);
switch(type)
{
case "金卡":
return new GoldenMember();
case "银卡"
return new SilverMember();
}
return null;
}
static protected string GetMemberTypeByID(id)
{
string type;
// get type by id
...
return type;
}
}
class Member
{
protected Member()
{
}
virtual public GetDiscount()
{
return 0;
}
virtual public GetReturnPoint()
{
return 0;
}
}
class GoldenMember
{
override public GetDiscount()
{
return 10;
}
override public GetReturnPoint()
{
return 1.5;
}
}
class SilverMember
{
override public GetDiscount()
{
return 5;
}
override public GetReturnPoint()
{
return 1;
}
}
也就是说，你不是说不同级别的客户有不同的折扣策略吗？策略模式啊。老子design pattern白学了？哈哈。
这个方案其实不错。简明易懂。可以轻易扩展出白金卡，钻石卡，九天十地菩萨摇头怕怕霹雳金刚雷电卡等等。
不过，age0同学开始憋坏了。他不知道跟老板进了什么谗言，老板愣插进来乱七八糟地提了一大堆新的需求。比如： 引用: 对于女性会员，决定在3.8当天在原来的优惠基础上增加5个百分点的折扣 所谓“始作俑者，岂无后乎？”，坏消息还不算完，总结起来，目前的需求如下： 引用:
- 会员等级折扣，会员等级是最重要的分类，大部分方案都会在等级上面作文章，所以单独归为一类
- 条件型折扣，只有在符合特定条件下才会发生的折扣，比如前面针对女性会员节日的折扣
- 货物优惠折扣，这些方案根据货物制定，举个例子：客户单独买电视或音响不会有任何折扣，一起买则会得到5%的折扣，电视+音响+DVD组合更会得到7%的折扣。
在一般情况下，这些折扣方案所产生的折扣是累加的（1+2+3），但是不排除其他可能性，例如2中可能出现的排它性条件折扣，也就是说这些折扣方案有可能会出现相对复杂的组合关系。 而且，更要命的是，不知道明天age0同学会不会又给老板出什么损招。（这老板莫不是age0的小舅子？ Laughing ）
于是，早先的OO设计面对这种乱拳打死老师傅的外行老板，有些秀才遇到兵的感觉了。
在那个帖子的后面，一些高手还提出了一些OO的改进方案。不过，比我们最初看到的那个策略模式就复杂的多了。
本文里，我们还是看看CO怎么处理这种问题。
首先，大致分析一下我们的处境。所谓“动手的不如动嘴的”，我们上面有一个对技术狗屁不通却喜欢指手画脚的老板，还有一个让大家恨得牙痒痒的age0这个 狗头军师。这让我们对我们真正需要处理的需求茫然不知所措。老板今天说对女性优惠，明天就可能说对单身18岁以下，胸围32C以上的才给优惠（我们有着从 来不惮以最坏的恶意推测自己老板的美德），肯给老板“大功告成”的干脆白送，外带小费。（NND，开始YY自己是那个老板了Smile）
从技术上说，这些“如何折扣”完全是非常多变的需求。把这些需求写成OO，CO，AO, PO并不是关键。我们最主要的目的是把他们写在一个统一的容易更改的模块中。不管明天老板出什么新的妖蛾子，我们都在一个模块中更改或者增添新的需求。
这个模块可以用Java, groovy, ruby, xml，这些都是可以考虑的方案。 Quake Wang就用bean shell的脚本写了一个解决方法。 java代码:
public class BeanShellDiscountStrategy implements DiscountStrategy {
public static final String DISCOUNT_BY_POINT = "if(member.point > 5) return 0.05; else return 0.02;";
public static final String DISCOUNT_BY_GENDER = "if(member.gender == 0) return 0.01; else return 0.03;";
private Interpreter i = new Interpreter();
private String discountScript;
public BeanShellDiscountStrategy(Member member, String discountScript) {
this.discountScript = discountScript;
try {
i.set("member", member);
} catch (EvalError e) {
throw new RuntimeException(e);
}
}
public double getDiscount() {
try {
return ((Double) i.eval(discountScript)).doubleValue();
} catch (EvalError e) {
throw new RuntimeException(e);
}
}
//getters and setters
public String getDiscountScript() {
return discountScript;
}
public void setDiscountScript(String discountScript) {
this.discountScript = discountScript;
}
}
这个方法，把多变的业务逻辑转移到bean shell脚本中，一定程度地减少了工作量。我们可以用ioc，把不同的脚本注射进去来得到不同的行为。
然而，这个方法对复杂的业务逻辑并没有提供什么本质性的解决方案。它没有提供把简单的规则组合成复杂规则的方法。比如前面age0给我们提出的“排他 性”。三个规则，如果第一个成功了，就用第一个，否则顺序执行第二个，第三个，直到某一个规则成功。这种逻辑，实际上已经不是在操作具体折扣，而是在操作 规则本身。
我们希望能够写： exclusive(rule1, rule2, rule3)，而不用关心rule1, rule2, rule3到底都是些什么rule。
类似的规则还有一些，比如：如果rule1返回true，才计算rule2；如果rule1返回false，才计算rule2；如果rule1的 返回值等于某个预定值，才计算rule2；只有rule1和rule2都返回true，才计算rule3；把rule1和rule2的结果加起来；把一系 列的rule的返回值起来；取rule1, rule2, rule3中返回值最大的。等等等等。这些，简单地用bean shell脚本是没用的。
头大了吧？嘿嘿。
其实，这是好消息呀。
我们前面分析了，老板是凶残的，斗争是残酷的，需求是不可预测的。但是，上面的这些组合，却是往往不会变的。因为老板毕竟还是人嘛，他的逻辑毕竟还是跑不出我们普通的“如果，那么”，与，或，非，加减乘除等等。
变化的，往往只是老板怎么组织这些“如果，那么”罢了。
变化的东西我们不好掌握，但是这些不变的东西还是可以啃一啃的。如果我们把这些搞定了。那么不管age0给老板出什么馊主意，我们都可以更轻松的应对。
比如： java代码:
Rule single = married.not();
Rule young = age < 18;
Rule good = breast > 32C;
Rule boss_likes = and(single, young, good);
Rule boss_pays = and(boss_likes, 大功告成able);
Rule paid_by_boss = boss_pays.then(120);
Rule big_discount = boss_likes.then(50);
Rule boss_afair = exclusive(paid_by_boss, big_discount);
哈，老板啊，您的代号为“选美”的折扣计划搞定了。
嗯。yy结束。理想是真美好啊。那么，怎么变成现实呢？熟读经典yy文学（武侠小说，比如说）的我们，一定知道被狗屎运缠身所烦恼的主角的成功方 法，那就是：夏梦————对不起，是“瞎蒙”，拼音输入给搞错了。（传说yy大师金老先生从前的yy情人就叫夏梦还是“瞎蒙”来着？小生八卦功力浅薄，也 不知是否和老先生的作品yy风格有不可说的联系？）
就是说，管你东邪吸毒多狠，管你大轮明王多拽，老子我一不用研究你的武功招式，二不用找领导给你穿小鞋，闭着眼睛，乱走一气凌波微步你也拿我没辙。咱就是运气好，你咬我？
咱们下面就来当一把段呆子。把你的ipod nano耳机戴上，音乐音量放到最大，不要理老板在那唧唧歪歪，什么折扣？什么客户？俗！ 咱们还是研究一些伏羲六十四卦，洛神的美妙步法（或者美妙身材也行啊。哈哈）。
所谓太极生两仪，两仪生四象（不是“思想”，更不是“死相”），一个rule的基本是什么？其实很简单，不过是两条： 1。它是否能用？一个对大mm美女的rule不能用在如花身上。 2。它生成的结果。
这个rule还要知道很多facts。于是，一个Rule的接口可以这样定义：
java代码:
interface Rule{
boolean apply(RuleContext facts, Variant result);
}
返回的boolean值表现这个rule是否可用。 那个Variant类型的result是一个placeholder，用来接收rule生成的结果。 RuleContext给rule提供所有需要的信息。
完了，Rule的定义就这样了。失望吧？
下面来看看前面我们说到的那些组合： ExclusiveRule用来实现排他性组合：
java代码:
class ExclusiveRule implements Rule{
private final Rule[] rules;
boolean apply(RuleContext facts, Variant result){
for(Rule rule: rules){
if(rule.apply(facts, result))
return true;
}
return false;
}
}
java代码:
IfElseRule用来实现简单的if-else逻辑：
class IfElseRule implements Rule{
private Rule cond;
private Rule consequence;
private Rule alternative;
boolean apply(RuleContext facts, Variant result){
if(!cond.apply(facts, result)){
return false;
}
if(result.getBoolean()){
return consequence.apply(facts, result);
}
else{
return alternative.apply(facts, result);
}
}
}
NotRule用来把一个rule的bool返回值取反： java代码:
class NotRule implements Rule{
private Rule rule
boolean apply(RuleContext facts, Variant result){
if(!rule.apply(facts, result)) return false;
result.setBoolean(!result.getBoolean());
}
}
AndRule用来把两个rule的bool值进行逻辑与： java代码:
class AndRule implements Rule{
private Rule rule1;
private Rule rule2;
boolean apply(RuleContext facts, Variant result){
if(rule1.apply(facts, result)){
if(!result.getBoolean())
return true;
}
if(rule2.apply(facts, result){
if(!result.getBoolean()){
return true;
}
}
result.setBoolean(true);
return true;
}
}
类似地，OrRule用来进行逻辑或。
其他的加减乘除，取最大值，都可以用类似的方法实现。我就不赘述了。
另外一点需要注意的，是我们实现了ifelse，但是前面所述的组合逻辑中我们只是说如果mm漂漂就如何，没有说不漂漂如何。不能简单地认为不漂漂就不给折扣，在排它性组合中，一个规则是否被应用了决定后续其它规则是否有机会被执行。
不过，我们仍然可以用ifelse来处理单纯if的情况。只需要定义一个NilRule就好了。这个Rule干脆不返回任何值，它永远都是一个不会被应用的规则（也就是说，apply()函数必然返回false） java代码:
class NilRule implements Rule{
boolean apply(RuleContext facts, Variant result){
return false;
}
}
这样，new IfElseRule(ppmm_rule, big_discount_rule, new NilRule());就是一个仅仅对ppmm有效的rule。
上面的这些Rule的基本组合实现，还是有一些重构的空间的。不过目前的实现更加简单，也足以表达CO的思想，所以，进一步的重构我就不做了。
在前面YY时，我们用了rule1.then(...), rule.not()这种东西。而现在的Rule接口只有一个apply()，要做rule.not()必须写"new NotRule(rule)"，语法上相对繁琐一些。
为此，我们可以把Rule从接口变成抽象类，把一些常见的组合子放进去，于是我们就可以有rule.not(), rule.ifelse(a,b), rule.then(a), rule.unless(b)等等更加方便干净的语法了。
呵呵，到此为止，我们的迷你规则引擎已经建设得七七八八了。之所以这么顺利，都要归功于你的ipod的音乐，它让我们可以把老板的喋喋不休抛在一边，装作就象盘古开天辟地以来就从来没有那些混账需求一样。世界清静了，我们才得以专心欣赏洛神曼妙的步履和身材。
学会了伏羲八卦，实现了这些可以反复重用的组合规则之后，就剩下实现具体的原子规则了。比如，取得客户性别，胸围等。
这些信息我们都假设可以从RuleContext得到。
那么，可以写一个SimpleRule来简化这些原子规则的创建：
java代码:
abstract class SimpleRule extends Rule{
boolean apply(RuleContext facts, Variant result){
result.set(run(facts));
return true;
}
abstract Object run(RuleContext facts);
}
对取得性别这个原子规则，我们就可以这样写： java代码:
class GenderRule extends SimpleRule{
Object run(RuleContext facts){
return facts.getGender();
}
}
这些原子规则可能不多，也可能不少。不过，总之是比把所有逻辑都实现在一起要简单多了。而且，如果使用一些脚本语言来包装这些规则的话，这些原子规则往往可以很简单地从closure中直接构造出来，不用每次单独写一个java类。
实际上，当你发现你需要在一个Rule实现里面放很多代码的时候，往往可以停下来想一想了，很有可能这个Rule本身可以有若干个小规则组合而成，不用费劲写了。
最后，让我们精彩回放段呆子凌波微步戏鸠摩智的片断（一个应用我们这个mini rule engine的测试代码）：
java代码:
package jfun.cre.demo.test;
import java.util.Calendar;
import java.util.Date;
import jfun.cre.Rule;
import jfun.cre.Variant;
import jfun.cre.demo.MyRuleContext;
import jfun.cre.demo.MyRules;
import junit.framework.TestCase;
public class SimpleTestCase extends TestCase{
private Rule getRule(){
final Rule gold_member = MyRules.discountByMember("gold", 0.1);
final Rule silver_member = MyRules.discountByMember("silver", 0.05);
final Rule platinum_member = MyRules.discountByMember("platinum", 0.2);
final Rule by_member = MyRules.any(new Rule[]{platinum_member,
gold_member, silver_member});
final Rule is_female = MyRules.isGender("female");
final Rule is_female_day = MyRules.isMonth(Calendar.MARCH)
.and(MyRules.isDay(8));
final Rule female_discount = is_female.and(is_female_day)
.then(MyRules.discount(0.05));
final Rule tvspeaker = MyRules.purchased(new String[]{"tv","speaker"})
.then(MyRules.discount(0.05));
final Rule tvspeakerdvd = MyRules.purchased(new String[]{"tv","speaker","dvd"})
.then(MyRules.discount(0.07));
final Rule by_purchase = MyRules.any(new Rule[]{tvspeakerdvd, tvspeaker});
final Rule final_discount = MyRules.productDouble(new Rule[]{
by_member, female_discount, by_purchase
});
return final_discount;
}
public void test1(){
final MyRuleContext mrc = new MyRuleContext();
final Variant result = new Variant();
assertTrue(getRule().apply(mrc, result));
assertEquals(0.837, result.getDouble());
}
public void test2(){
final MyRuleContext mrc = new MyRuleContext(){
public Date getNow(){
Calendar cal = getCalendar();
cal.setTime(super.getNow());
cal.set(Calendar.MONTH, Calendar.MARCH);
cal.set(Calendar.DAY_OF_MONTH, 8);
return cal.getTime();
}
};
final Variant result = new Variant();
assertTrue(getRule().apply(mrc, result));
assertEquals(0.837*0.95d, result.getDouble());
}
}
以上是直接用java来使用这个库。更爽一点的，是用脚本语言做一个dsl出来，我用jaskell做了一个，长成这个样子：
我刚刚完成了用jaskell给我的这个rule combinator包装的外壳，结果程序如下： jaskell代码:
final_discount where
Calendar = jaskell.java.import "java.util.Calendar";
isMonth m = eq(m, cre.datepart "MONTH");
isDay d = eq(d, cre.datepart "DAY_OF_MONTH");
purchase ctxt = ctxt.getPurchasedProducts[];
purchased product = do {products=purchase} $
products.contains[product];
purchased_all products = cre.and(jaskell.prelude.map purchased products);
discount d = return (1-d);
cardtype ctxt = ctxt.getCardType[];
gender ctxt = ctxt.getGender[];
discountByMember type v = (eq type cardtype).then (discount v);
gold_member = discountByMember "gold" 0.1;
silver_member = discountByMember "silver" 0.05;
platinum_member = discountByMember "platinum" 0.2;
by_member = cre.any[platinum_member, gold_member, silver_member];
is_female = eq "female" gender;
is_female_day = cre.and[isMonth(Calendar.MARCH), isDay 8];
female_discount = discount 0.05 `when cre.and[is_female, is_female_day];
tvspeaker = discount 0.05 `when purchased_all["tv", "speaker"];
tvspeakerdvd = discount 0.07 `when purchased_all["tv", "speaker", "dvd"];
by_purchase = cre.any[tvspeakerdvd, tvspeaker];
final_discount = cre.fold (*) 1 [by_member, female_discount, by_purchase];
end
那个"do{product=purchased} $"对应的就是"do product<-purchased"。
这个Rulet库的api文档可以在这里看到：
Rulet API
在这里下载：
doownload from codehaus